Secure access to physical and digital assets using authentication key

ABSTRACT

Authorized access to a digital asset is obtained by associating an authentication tag with a physical object accessible to a user, by configuring the tag with a first dataset comprised of a random distribution of three-dimensional elements and with a second dataset comprised of machine-readable data elements, and by authorizing a mobile device to scan the elements. The first and second datasets together comprise an authentication key that uniquely identifies the object and, in turn, the user. The authentication key is scanned by a device in response to a prompt from the digital asset to obtain scanned key data. Predetermined key data and a device identifier indicative of the authorized device are stored in a database. Access to the digital asset is allowed when the scanned key data matches the stored predetermined key data, and when the device scanning the data is authorized.

BACKGROUND OF THE INVENTION

In the digital economy, securing and allowing access to information onlyby authorized owners is essential in order to safeguard both physicaland digital assets. In a typical setup in most companies, individualsuse a user name and a password to connect to a server or website. Thisapproach is incredibly vulnerable; if someone gets hold of the password,they can login pretending to be the user of that account. Since it isdifficult to remember all the passwords a person may have used onvarious websites, people normally use only one password for most of thesites or servers with which they connect. If the security of any one ofthese sites is breached, the passwords may leak out, and a hacker mayaccess part of the digital information for that individual stored atvarious websites. This may include bank information, investmentaccounts, wills, private information, sensitive records, etc.

People also keep a large number of identifying articles with them. Thesecould be cards in their wallet, pockets, or purses. These cards includecredit/debit cards, driver's licenses, ID cards, loyalty cards, bordercrossing cards, government issued cards for accessing benefits, voteridentification cards, military cards, and health cards, amongst others.The purpose for these cards is different, and therefore one has nochoice except to carry all these cards as needed. The identifyingarticles need not be in the form of cards. They could be keychains,separate custom plastic tags, custom key tags, hand tags, and key fobs,and the like.

Key fobs are among a class of physical hardware tokens that may alsoinclude smart cards and proximity cards. These hardware tokens are oftensmall enough for users to store on key rings, in their wallets, or intheir pockets. In an enterprise, key fobs may also be used to enabletwo-factor and multifactor authentication and to safeguard access to acompany's network and data. Biometric authentication may also beincorporated into hardware tokens. Some devices use the traditionalfingerprint method, while others require users to swipe the key fob.This action reads the fingerprint ridges, but also the finger pad'sseven layers of skin to authenticate the user. Software tokenapplications can offer the same authentication capabilities as thehardware tokens. A user can install a software token application ontheir smartphone to avoid carrying a physical device on their key ring.

It would be ideal if a person could carry only one Unique Identity andAuthentication Key (UIAK) or key in the form of a physical item, card,key fob, or single identifying article that serves all these purposes inaddition to allowing access to a website or any secure server. This itemcan serve as a credit/debit card, health card, ID card, governmentbenefit card, loyalty card, etc., and can also be used as an item thatuniquely qualifies a user, allowing a multifactor authentication toaccess a website or server without a password. It would therefore bedesirable to provide methods and systems to assure the security inaccessing any physical or digital asset by using the UIAK.

In order to strengthen the security for accessing websites or serversand to reduce the possibility of hacking by unauthorized entities andindividuals, multifactor authentication techniques have grown rapidlywith most enterprises and individuals. This helps secure digital assetsin the wake of cyber attacks, hacking, and heists.

There are three generally accepted factors that are used to establish adigital identity for authentication, including a knowledge factor, whichis something that the user knows, such as a password, answers tochallenge questions, ID numbers, or a PN. The second factor is apossession factor: something that the user has, such as a mobile phoneor a token. The third factor could be a biometric factor, which issomething that the user is, such as his or her fingerprints, eye scan,or voice pattern.

Combining two or more such factors allows for reliable authentication.It is always recommended to use multifactor authentication for thatreason. Two-factor authentication (2FA)-based, one-time password (OTP)techniques, which use basic unique individual identification factors forauthentication, have done much to secure end users. Most 2FA uses theknowledge factor and the possession factor.

If 2FA is not enabled, the enterprise server typically monitors unusualsign-in attempts (such as one originating from a new device located in adifferent country or continent), or from a location that is not thenormal location of the device. If the location is considered suspect,the server may prompt the user to confirm their account. The server maysend a verification code or a request to change the password to anexisting backup email address that was previously configured for thataccount. However, even receiving and entering such a code and answeringall the additional security questions may not be enough to confirm useridentity.

2FA adds an additional factor: typically a one-time code sent to, orgenerated on, a user's mobile device when a user logs in to his/heraccount from a new device or location. Someone trying to break into auser's account needs to not only steal the password but also, in theory,have access to the mobile device when they try to log in. 2FA is abetter way to protect online accounts.

Thus, 2FA provides an extra layer of security to keep the data safeirrespective of the strength of the password. But a 2FA setup—which formost users requires a temporary code generated on, or sent to, a phonein addition to a password—is not necessarily bulletproof. This isespecially so if that second factor is delivered via text message.

There are various 2FA adaptations. In one adaptation, the server sends amessage to a mobile device via SMS when someone tries to log in or avoice mail code on any phone. Even if one uses a dedicated app on aphone to generate codes, there is a good chance that the serviceprovider offers to let people log in by sending an SMS code to one'sphone. Or, the service may allow you to remove the 2FA protection fromyour account after confirming that you have access to a phone numberthat you configured as a recovery phone number.

The rationale for text-based SMS or a voicemail-based code is quitesimple. A cell phone has a unique phone number, and it has a physicalSIM card inside it that ties it to that phone number with the cell phoneprovider. However, the phone number is not as secure as one would liketo believe.

For example, an attacker may call the cell phone company's customerservice department and pretend that the cell phone was lost. The phonecompany may ask some personal details about you—for example, credit cardnumber, last four digits of a SSN, and others—that regularly leak in bigdatabases and are used for identity theft. The attacker can try to haveyour phone number moved to their phone. There are even easier ways. Forexample, the attacker can have call forwarding set up on the phonecompany's end so that incoming voice calls are forwarded to their phone.Thus, the phone number becomes the weak link, allowing the attacker toremove two-step verification from the account or for the attacker toreceive the two-step verification codes via SMS or voice calls. It isnot just about the phone number, either. Many services allow 2FA to beremoved if the phone is lost. As long as you know enough personaldetails about the account, you may be able to gain access. Indeed, someexperts claim that 2FA using SMS text messages or voice mail based codesis not technically 2FA at all.

Fake cell phone towers known as International Mobile Subscriber Identity(IMSI) catchers or “stingrays” can also intercept text messages. Thesecurity community has identified weaknesses in SS7, i.e., the protocolthat allows telecom networks to communicate with each other. Hackers canexploit SS7 to spoof a change to a user's phone number, interceptingtheir calls or text messages.

These attacks are not exactly easy to pull off, and likely require theattacker to figure out the user's cell phone number in addition to thepassword that they have stolen, guessed, or reused after beingcompromised in a data breach from another hacked service. But for anyonewho might be a target of sophisticated hackers, all of those techniquesmean that SMS should be avoided when possible for anythinglogin-related.

The other adaptation of 2FA is technology such as Google Authenticator,which generates a unique Time-based One-time Password (TOTP) or code ona mobile device that matches one generated simultaneously on a webservice's server. Based on some crypto tricks, this approach does notinvolve any communication between the server and the mobile device. ATOTP verifies user identity based on a shared secret. This secret mustbe shared online between the user and the provider. When logging into awebsite, the user device generates a unique code based on the sharedsecret and the current time. The user then manually submits this code asthe second factor. The server generates the exact same thing based onthe same secret in order to compare and validate the login request. Bothsides generate the same hash from the same input factors, and share asecret at registration.

Apps such as Google Authenticator generate one-time-password (OTP) codesthat change every few seconds. Those same exact codes are generated onthe servers run by services like Slack, WordPress, or Gmail, so that theuser can generate the code to prove their identity without it ever beingsent over the internet. When the user signs up for the service, theGoogle Authenticator app and the server both start with a seed valuethat is transformed into a long, unique string of characters with a“hash”, i.e., a mathematical function that cannot be reversed. Then,that string of characters is hashed again, and the results are hashedagain, repeating every few seconds. Only a few digits of thosecharacters are displayed as the login code, so that no one who glancesat a user's phone can start their own hash chain.

While TOTP is simple to use, it has certain shortcomings. The user andthe provider server share the same secret. If an attacker is able tohack into the provider server and is able to obtain the password and thesecret database, the attacker can access all the accounts. Additionally,the secret is displayed in plain text or as a QR code. This also meansthat the secret is most likely stored in plain text form on the serverof the provider. Basically, one needs to trust that the provider canprotect the secret.

Most OTP systems are susceptible to real-time replay and socialengineering attacks and are also indirectly susceptible to man in themiddle (MITM) and man in the browser (MITB) attacks. A real-time replayattack is a form of an MITM attack. In this attack, malware sitting onthe browser captures the user credentials. The malware forwards thesedetails to the attackers, and simultaneously blocks the user request.The user receives an error message which reports a failure. The attackercan perform an immediate replay with the same credentials. These tokensare usually valid for 60 seconds.

There have been reports where a vendor stored the seeds for all itsreleased tokens, and its servers were compromised. With the OTPgeneration algorithm being public, the attackers could derive OTPs forleaked seeds.

There are other adaptations of 2FA. For example, in Google's Prompt, asecond-factor login prompt is sent directly from its servers to Androidphones or to the Google Search app for iOS. Google Prompt works bypushing an interactive verification prompt through GCM (Google CloudMessaging), which is available on Android devices as part of GoogleCloud Platform and on iOS devices as part of the Google app. Being asimple “Yes” or “No” message delivered to a trusted device does notrequire opening an app or entering codes. If the user cannot receive theprompt, they can easily select a different authentication method (e.g.,a code generated in the authenticator app or delivered in a textmessage). Users cannot respond to Google Prompt on locked devices.

In addition to TOTP, another approach is based on a Universal SecondFactor (U2F). The U2F standard was created by the FIDO Alliance. U2Fuses public key cryptography to verify user identity. In contrast withTOTP, users are the only one to know the secret (i.e., the private key).The server sends a challenge, which is then signed by the secret(private key). The resulting message is sent back to the server, whichcan verify the identity by using the user's public key in its database.

There are several benefits of using U2F authentication. There is noshared secret (private key) sent over the internet at any time. Becausethere is no secret shared in U2F and no confidential databases stored bythe provider, a hacker cannot simply steal the entire databases to gainaccess. Instead, the attacker needs to target individual users, and thatis much more costly and time-consuming. U2F is easier to use because noretyping of one-time codes is involved and no personal information isassociated with the secret.

In one approach, the U2F protocol has been implemented using a USB tokendevice that features a button to activate the device. The server sends achallenge request to the client's web browser, and then the browsersends the request to the USB device. The USB device lights up, promptingthe user to push the button to activate the device. Once activated, thedevice signs the challenge and returns the signed data back to thebrowser, which forwards it back to the server. The USB-only tokens areonly useful for computers; this prevents their use on mobile devices.There are a few U2F devices on the market now that use NFC or Bluetoothin addition to USB. Adoption of the U2F standard is accelerating withmany web services are using it, such as Facebook, the entire Googleplatform, Dropbox, and GitHub.

When applied, the U2F standard ensures that 2FA is used for loginsecurity by requiring both a knowledge factor (password) and a physicalfactor (USB key or token) in order to authenticate access to a securedaccount or service. It also ensures that access is granted only afterverifying that the login site or service is truly a legitimate property.

However, U2F is not going to solve all cybersecurity problems, but it iscertainly a step in the right direction. For example, researchersrecently uncovered some flaws in the USB design specifications that mayleave firmware unprotected and potentially allow attackers to overwritefirmware and take control of USB devices. This firmware vulnerabilitycould allow USB devices to be reprogrammed to steal the contents ofanything written to the drives and spread malicious code to any computerto which these devices are connected. Much like self-replicatingcomputer viruses that once spread through the insertion of floppy disksinto disk drives in the past, USB malware can potentially infect systemsand easily replicate itself and spread to other devices. These dangersare underscored by the fact that they are essentially undetectable.Currently, there is no process in place to check or confirm authenticitywhen a device's firmware is flash upgraded. Since these changes occur atthe firmware level, antivirus or malware tests cannot detect suchmalicious code.

Of course, some USB devices do not have reprogrammable firmware, so notevery device may be vulnerable in this way. However, users areultimately at the mercy of manufacturers. While some do not usereprogrammable firmware, it is always technically possible for maliciouscode to be injected into USB devices at the manufacturing stage. Even ifthe firmware is intact, USB is still highly vulnerable because anotherwise ‘clean’ and uninfected USB device can potentially becomeinfected by being connected to a computer that has been compromised bymalware. So, even if a USB device's firmware is intact, it canpotentially be infected without the user's knowledge, and the user mayunwittingly connect that device to additional systems which cansubsequently be compromised. Thus, the potential risks of USB technologyare not limited to firmware vulnerabilities only. The mere use andavailability of USB connections and devices poses similar, disturbingdata security risks.

Infected USB devices can behave maliciously. For example, a USB devicecan emulate a keyboard and issue its own commands, includinginstructions to install malware or steal files; a USB device can pretendto be a network card and change a computer's domain name system setting,which can secretly redirect your web browsing traffic; a USB device caninstall malicious code that acts as a man-in-the-middle and secretlyspies on communications as it relays them from a compromised machine; ora USB thumb drive or external hard disk can infect connected computersat boot up, before antivirus tools can detect it and intervene.

In another approach to defeat USB authentication, a researcher used asmall microcontroller to evade various security settings on a realsystem, opened a permanent backdoor, disabled a firewall, and controlledthe flow of network traffic, all within a few seconds and permanently,even after the device has been removed.

The mere act of connecting a USB device to a machine can potentiallylead to malware infection and a data security breach. This is whyexperts such as the United States Computer Emergency Readiness Team(US-CERT) recommend that users never connect USB devices tountrustworthy machines such as public computer kiosks and never connectthem to home or enterprise systems unless they know and trust everyconnection that the device has ever made. This is why most defenseagencies and defense contractors only buy computers that do not have anyUSB connections. Their employees thus cannot use USB authentication.

Instead of using the knowledge factor and the possession factor, one canalso use the third factor such as a biometric factor, which is somethingthat the user is, such as his or her fingerprints, eye scan, or voicepattern. While the biometric factor is the most convincing way to provean individual's identity, it has several drawbacks. Biometricauthentication is a “what you are” factor and is based on uniqueindividual characteristics. Physical biometrics includes DNA,fingerprints, facial recognition, and eye scans (iris, retina).Behavioral biometrics includes voice recognition and handwrittensignatures.

However, biometric authentication systems are not 100% accurate.Environment and usage can affect biometric measurements. They cannot bereset once compromised and you cannot revoke the fingerprint, eye scan,or voice print remotely. A thief could steal the smartphone, create afake finger, and then use it to unlock the phone at will. It has alsobeen found that master fingerprints can trick many phones and scanners.

When a fingerprint is registered in a device, the device asks formultiple presses from different angles. These samples are then used asthe original data sets to compare with subsequent unlock attempts. Sincesmartphone sensors and other mobile device sensors are small, they oftenrely on partial matches of fingerprints. Researchers have discoveredthat a set of five master fingerprints can exploit these partialmatches, and open about 65% of all devices. Since there is no way tomodify your iris, retina, or fingerprint, once somebody has a workingcopy of these, there is not much you can do to stay safe.

In one of the biggest hacks ever, the US Office of Personnel Managementleaked 5.6 million employee fingerprints. For the people involved, apart of their identity will always be compromised. Unlike passwords,fingerprints last a lifetime and are usually associated with criticalidentities. Thus, the leakage of fingerprints is irredeemable.

A couple of years ago, a security researcher discovered weaknesses inthe software that allowed Android devices to be compromised, allowingthem to remotely extract a user's fingerprint, use backdoors in thesoftware to hijack mobile payments, or even install malware. What ismore, they were able to do this remotely, without having physical accessto the device. Creating a fake fingerprint is not that difficult. Anattacker can lift a fingerprint from the phone or any other place, placeit on a plastic laminate, and then cast a finger to fit this mold. Oncethe malicious hacker creates the fake finger, all he has to do is toplace it on the scanner, press with his finger to conduct electricity,and then use the unlocked phone.

Tricking an eye scanner may require taking a photo with a cheap camerain night mode, or getting access to the hacked data from a site thatstores the eye scan data. After printing the eye on paper, a wet contactlens is put over it to mimic the roundness of the human eye.

At times, third party authentication services are used to authenticate auser. For example, OpenID is a way of identifying a user, no matterwhich web site they visit. Web sites that take advantage of OpenID neednot ask for the same information over and over again. A user only givesthe password to the OpenID provider, and then the OpenID providerassures the identity of the user to the websites a user is visiting. Nowebsite other than the OpenID provider ever sees the password, so a userdoes not have to worry about an insecure website compromising his/heridentity. Thus, OpenID simplifies login. With OpenID, a user only has toremember one user name and one password. However, Open ID alone does notguarantee security, because it still remains the single point offailure. The other approach used by some websites is OAuth forauthorization and partial authentication.

OAuth is an open standard for authorization and allows delegatedauthorization of devices, APIs, servers, and applications with accesstokens rather than credentials. A user grants permission to accesshis/her data on some website to another website, without providing thiswebsite the authentication information for the original website. OAuthdoes not validate a user's identity but provides authorization to seewhat permissions an existing user already has. There are various modesof authorizations called grant types depending on the service orapplications. Basically, OAuth is a protocol that supports authorizationworkflows and provides a way to ensure that a specific user haspermissions to do something.

Both protocols provide a way for a site to redirect a user somewhereelse and come back with a verifiable assertion. OpenID provides anidentity assertion while OAuth is more generic in the form of an accesstoken which can then be used to “ask the OAuth provider questions”.However, they each support different features. They share a commonarchitecture in using redirection to obtain user authorization. InOAuth, the user authorizes access to their protected resources, and inOpenID to their identity. However, that is all they share. At theircore, both protocols, OpenID and OAuth, are assertion verificationmethods. OpenID is limited to the ‘this is who I am’ assertion, whileOAuth provides an ‘access token’ that can be exchanged for any supportedassertion via an API.

Because the identity provider typically (but not always) authenticatesthe user as part of the process of granting an OAuth access token, it istempting to view a successful OAuth access token request as anauthentication method itself. However, because OAuth was not designedwith this use case in mind, making this assumption can lead to majorsecurity flaws.

The OAuth communication protocol is not secure and the user can beimproperly tricked such that an attacker can obtain his/her credentials.Thus, OAuth should be used only if it is actually needed. For example,building a service where it needs to use a user's private data that isstored on another system.

Similarly, OpenID is an authentication protocol where a third partyprovides authentication for all other sites without sharing the username and password with each site. OAuth is an authorization protocolwhere credentials can be shared and permission can be granted and somedata can be shared with other sites through the use of tokens. However,both of these approaches are subject to security breaches.

Therefore, sophisticated attackers are capable of breaking the presentmultifactor authentication and the third party ID provider's services.Thus, there is a clear need to come up with a better approach to securephysical and digital assets from cyber attacks, hacking, and heistswhile providing authentication and authorization in a secure manner andpreferably through a single protocol without sharing a user name otherthan with the authentication site.

In addition, there have been numerous cases of fraudulent transactionsinvolving credit/debit cards, ATM cards or ID cards. Most credit cardsnow incorporate an electronic chip on the card known as an EMV (Europay,MasterCard, and Visa) chip to prevent counterfeiting. Using an EMVChip+PIN at the physical Point Of Sale (POS) reduces card-present (CP)fraud significantly but does not address the fraudulent use of paymentdata when there is no direct connection between the chip reader and thecard, such as when the data is entered into an e-commerce application.Such fraud, termed card-not-present (CNP) fraud, remains an increasingproblem.

The advantages of chip cards over magnetic stripe cards are many andhave reduced CP fraud significantly in countries that have adopted it.The card's chip may or may not operate in conjunction with a PIN. Ifused with a PIN, it provides 2FA that combats the use of lost or stolencards. A cryptogram in the chip authenticates the card's validity andthe PIN entry validates that the person using the card is thecardholder. The smart chip in the card must connect with a reader in thepoint-of-sale (POS) terminal. The connection can either be physical(i.e., touching) or wireless using near-field communication (NFC)technology over distances of a few inches. However, as mentioned above,it does not address CNP transactions because the user normally does nothave access to a chip reader.

One possible solution to prevent CNP fraud is for consumers to purchasean EMV-compliant card reader to use for authenticating a credit or debitcard for online purchases or banking sessions. However, this requiresthe consumer to outlay their own money, and makes completing onlinetransactions more difficult. This is especially true with the rise ofmobile transactions, where a user would need to carry an extra devicewith them at all times in order to access their accounts. It is alsopossible that an NFC card reader could be built into or attached todevices such as desktop computers, tablet computers, or mobile devicesin the future. However, this is reliant on manufacturers creating suchdevices and on users then purchasing these devices.

Other proposed authentication mechanisms to fight CNP fraud includeShort Message Service (SMS) authorization codes and Universal Serial Bus(USB) security tokens. However, these too suffer from the same problemsthat were described with 2FA in accessing websites or other digitalassets.

None of the above approaches are satisfactory to prevent CNP credit cardfraud. It would be ideal if a person can carry only one UIAK in the formof a card, key fob, or single identifying article that serves manypurposes in addition to allowing access to a website. This UIAK canserve as a credit/debit card, health card, ID card, government benefitcard, loyalty card, bank card, etc. and can also be used as an item thatallows user to access websites or servers with or without a password.

In addition, cryptocurrencies, such as bitcoin based on computationalalgorithms, are gaining ground lately. They can be used to purchasegoods and services and exchanged for conventional currencies. Ascryptocurrencies are mined, they need to be stored. In order to spendthe bitcoin, two pieces of information are needed: the publicinformation and the private or secret information. The publicinformation identifies the identity of the coin and its worth and goeson the block chain. The public key is also the address of the bitcoin orcurrency where the coin needs to be sent. The secret information is theprivate key of the owner. The private key must be kept secret andprotected.

In order to manage the private key, three considerations must be kept inmind. First, the availability to spend the cryptocurrency when needed;second, the convenience of managing the key; and third, the security ofthe key, are some of the key criteria to manage. One way to manage theprivate key is to store it on a file on local storage media, such as amobile phone or a computer hard disk or any other device under thecontrol of the owner. It is easily available and convenient to manage.However, if the storage media is lost or stolen, or becomes infectedwith malware, the currency will be lost.

Theft of cryptocurrencies is not uncommon. In February 2014,cryptocurrency made national headlines due to the world's largestbitcoin exchange. Mt. GOX, declaring bankruptcy because it lost nearly$473 million of their customer's bitcoins, likely due to theft. In 2013,two agents from the Drug Enforcement Administration and U.S. SecretService were charged with wire fraud, money laundering, and otheroffenses for allegedly stealing bitcoin during the federal investigationof Silk Road, an underground illicit black market.

Thus, storing cryptocurrencies on a computer or local devices known ashot storage is fraught with dangers. Also, any device connected to theinternet is subject to being hacked and thus not secure. One way tomanage this is to store the cryptocurrencies offline or what is calledcold storage. Cold storage is not connected to the internet. This maynot be convenient, but it is more secure. In this manner, one can keepsome currency in hot storage for convenience, but most of it in coldstorage for security. One can move currency between cold storage and hotstorage and vice versa.

In order to manage hot and cold storage, the private keys must bedifferent for each storage. Otherwise, hacking the hot storage privatekey will also compromise the cold storage private key. Each side alsowill need to know the public addresses in order to move thecryptocurrencies. There are various ways to manage the addresses forcold and hot storages and moving the currency back and forth.

However, if the private keys of the hot storage or cold storage arehacked, the cryptocurrency will be lost forever. Most of the keys arestored in a single place, whether in a safe, in software, on paper, in acomputer, or in a device. This creates a single point of failure. If thesingle point of failure is compromised, then it becomes a problem. Whilethere are ways to avoid single points of failure by splitting the keysecrets and storing them at different places, it does createinconvenience and extra overhead.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of a basic framework of an authentication process.

FIG. 2A is a top plan view of an authentication tag used in theauthentication process.

FIG. 2B is a sectional view of the authentication tag of FIG. 2A.

FIG. 3 includes views of various objects on which the authentication tagof FIG. 2A may be applied.

FIG. 4 is a flow chart depicting an authentication method in which a keyon the authentication tag can be used to allow a user access to awebsite.

FIG. 5 is a flow chart depicting an authentication method in which a keyon the authentication tag and other information from a mobile device canbe used to allow a user access to a website.

FIG. 6 is a diagram of multiple security levels used to protect adigital asset.

FIG. 7 is a flow chart depicting a registration method in which a key onthe authentication tag can be used to allow user registration on awebsite.

FIG. 8 is a flow chart depicting a method in which a key on theauthentication tag and other information from a mobile device can beused to allow a user to login on a website using a user name.

FIG. 9 is a flow chart of a basic framework of a credit card transactionprocess.

FIG. 10 is a flow chart depicting a credit card transaction process inwhich a key on the authentication tag can be used to identify a user.

FIG. 11 is a flow chart depicting a credit card transaction process inwhich a key on the authentication tag can be used to complete thetransaction.

FIG. 12 is a flow chart depicting a credit card transaction process inwhich a key on the authentication tag and other information from amobile device can be used to complete the transaction.

FIG. 13A is a flow chart depicting a method in which a key on theauthentication tag and other information from a mobile device can beused to store a private key in storage media.

FIG. 13B is a view analogous to FIG. 6, in which the storage media ofFIG. 13A is secured by multiple security levels.

FIG. 14A is a display of card/asset/service icons to be accessed on amobile device.

FIG. 14B is a flow chart depicting a method in which a key on theauthentication tag and other information from a mobile device can beused to launch any of the icons of FIG. 14A.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The American National Institute of Standards and Technology (NIST) hasdescribed a basic framework 100 on how the authentication process can beaccomplished. As shown in FIG. 1, the first step requires the enrollmentprocess of an individual or applicant 110 applying to a CredentialService Provider 115 (CSP). The CSP 115 confirms the applicant'sidentity and the individual receives a token and/or a credential, whichmay be in the form of a user name. The individual 110 then becomes asubscriber 120.

The CSP 115 manages the credential along with the subscriber's 120enrollment data for the life of the credential. When an individualclaimant 130 wants access to a service provider or a Relying Party 140,he/she has to prove their identity as a subscriber 120. The relyingparty 140 (RP) is a computer term used to refer to a server providingaccess to a secure software application. Verifier 135 is the party thatverifies the claimant's 130 identity. The verifier 135 and the CSP 115may be the same entity; the verifier 135 and the relying party 140 maybe the same entity; or they may all be three separate entities. Wherethe verifier 135 and the relying party 140 are separate entities, theverifier 135 must convey the result of the authentication protocol tothe relying party 140. As described earlier, the verifier 135 may be athird party authentication provider that confirms the identity of theuser or claimant 130 for access to the relying party 140 server. OAuthand OpenID may act as the verifier 135 entities.

FIG. 2A and FIG. 2B show a top plan view and a sectional view,respectively, of an authentication tag 10 on an object 12 to beauthenticated, in a system 200, as described in U.S. Pat. No. 9,082,062B2, the entire contents of which are incorporated herein by referencethereto. In brief, the tag 10 includes a first dataset 14 configured asa random distribution of three-dimensional elements P1, P2, P3, P4, P5,P6, and P7 on the object 12, and a second dataset 16 configured as dataelements.

The data elements of the second dataset 16 are preferably also affixedto the object 12, either adjacent to, or superimposed on, the firstdataset 14. The data elements of the second dataset 16 aremachine-readable, for example, they can be light-reflective.Advantageously, the second dataset 16 is a barcode symbol printed on thetag 10, but could also be a serial number of alphanumeric characters, oran RFID tag, or a magnetic stripe. There could be different embodimentsof the second dataset 16. For example, instead of a barcode as thesecond dataset, it could be a serial number, or alphanumeric charactersin an RFID tag, or the second dataset may be comprised of bars, dots, orother shapes and characters. In an RFID tag, numerical or alphanumericcharacters can be stored in an RFID chip. The first dataset 14 may thenbe incorporated over the RFID tag. The second dataset 16 in the RFIDchip may be encrypted, and the decryption key can be limited to devicesthat can read it.

FIG. 2A and FIG. 2B show the datasets 14 and 16 on the same tag 10 thatis advantageously configured as an adhesive label. However, datasets 14and 16 can also be directly incorporated in any object 12 or article.The datasets 14 and 16 together constitute a Unique Identity andAuthentication Key (UIAK) or key 205 on the object 12. The key 205 canbe affixed to the object 12 in situ. The key 205 is associated with theobject 12 to be authenticated, and any object may be authenticated.Preferably, the label has a substrate, e.g., paper, foil, or film, andan adhesive layer 20 on the underside of the substrate for adhering thekey 205 to the object 12.

The three-dimensional elements P1, P2, P3, P4, P5, P6, and P7 of thefirst dataset 14 are configured as a plurality of light-modifyingparticles and/or bubbles and that can have any shape, color, material,interior structure (hollow or solid), size, or number. Thethree-dimensional P1, P2, P3, P4, P5, P6, and P7 can be of differentgeometrical shapes, such as rectangular, triangular, circular, or ovalareas, on the label. The three-dimensional elements can be mutuallyspaced apart or contact one another. The three-dimensional elements canbe deposited in a single layer or in multiple layers on the label, orcan be partially or fully embedded in a curable medium 18, and may beoverlaid with a transparent overcoat for protection. Suchthree-dimensional elements have characteristic colors, for subsequentimage processing and analysis. The three-dimensional elements are eitherapplied to the label for the object 12, e.g., by being ink jet-printedon the label, or by being applied in the curable medium 18 on the label,or by being adhered to the label, or by being applied or adhereddirectly to the object 12, or by being applied or adhered directly to acard on the object 12. The light-modifying particles are eitheroptically reflective or retro-reflective, or light-scattering, orlight-absorptive over one or more different wavelengths to exhibitdifferent colors.

A portable, handheld, image capture device is preferably aimed at thefirst and second datasets 14, 16 to capture return light from thethree-dimensional elements and the data elements. The return light fromthe datasets 14, 16 can be captured simultaneously or consecutively.Advantageously, the image capture device is a mobile electronic devicehaving a solid-state imaging module of the type conventionally found inconsumer electronic digital cameras. The mobile electronic device istypically a cellular telephone or smartphone that has a built-in imagingmodule, but can also be a personal digital assistant (PDA), a tablet, acomputer, an e-reader, a media player, or like electronic device havinga built-in imaging module, especially one that is normally readily athand to the average user. No special skill set is required for the userto capture the return light from the three-dimensional elements and thedata elements by simply taking picture(s) of the three-dimensionalelements and the data elements.

As described above, it is advantageous in several applications when theidentifying information of the second dataset 16 is in the RFID chip,and when the first dataset 14 is applied over the RFID chip. Forexample, it may reduce the overall physical dimension of the resultinglabel, and the reading of the identifying information may not require adirect line of sight as is the case for capturing return light from abarcode with an image capture device. With the advent of nearfield RFIDreaders and nearfield RFID chips, the identifying information of thesecond dataset 16 can be captured with a mobile device, and the samemobile device can also capture the optical fingerprint information inthe first dataset 14. Alternately, a fixed device that has an imagerintegrated into an RFID reader can also capture both the second dataset16 information and also the fingerprint image in the first dataset 14.

Reference numeral 300 in FIG. 3 shows another embodiment where thedatasets 14 and 16 in the form of the key 205, are incorporated on amagnetic stripe card or an electronic chip-based card 310. The key 205can be affixed either on the front of the card 310, or it could beaffixed on the back of the card 310 at a suitable place so as not tointerfere with an EMV (Europay, MasterCard, Visa) chip 315, or amagnetic stripe. The key 205 can be incorporated in the credit cardmanufacturing process itself.

The second dataset 16 can be associated with the information in themagnetic stripe or the EMV chip 315. For example, in a credit card thathas the EMV chip 315, and a magnetic stripe, the datasets 14 and 16 canbe embedded in, or attached to, the credit card 310, and the informationin datasets 14 and 16 can be associated with the card number or otherinformation in the chip 315. Alternately, the dataset 16 can be encodedin unencrypted or encrypted form in the magnetic stripe or the chip 315with the decryption key in a reading device. The reading device can be afixed device or a mobile device that reads the identifying informationin the second dataset 16 in the barcode or the chip 315 or the magneticstripe, and also captures the optical information of the first dataset14.

In other embodiments, the datasets 14 and 16 can be incorporated in, oraffixed to, any identifying document that a person has. For example, asalso shown in FIG. 3, the key 205 can be attached to an ID card 320 thata person carries with him/her. The key 205 can also be affixed to awrist band 325 or a pendant 330. Alternately, any item that a personowns can be made unique by affixing the key 205, and then, that itembecomes a passport to access digital assets, websites, servers, or touse as a credit/debit card.

As described in U.S. Pat. No. 9,082,062 B2, any object 12 may beauthenticated by creating an authentication pattern signature for theobject 12 to be authenticated, associating a random distribution of thethree-dimensional elements P1 . . . P7 with the object 12, aiming aportable, handheld, image capture device at the object 12 to capturereturn light from the elements P1 . . . P7 as one or more images,verifying from the image(s) that the elements P1 . . . P7 arethree-dimensional, processing the image(s) to generate an image patternof the elements P1 . . . P7, comparing the image pattern with theauthentication pattern signature, and indicating that the object 12 isauthentic when the image pattern matches the authentication patternsignature.

The authentication pattern signature for the key 205 may be stored in anaddressable database remotely from the key 205. The database stores amultitude of other authentication pattern signatures for other keys.When read, the second dataset 16 serves as an address identifier thatidentifies an address for the authentication pattern signature in theremote database, thereby enabling the database to be interrogated onlyat that address, rather than having to interrogate every authenticationpattern signature in the database. This greatly acceleratesauthentication and improves field performance.

The data elements of the second dataset 16 are machine-readable, forexample, they can be light-modifying, as described above. When the dataelements reflect and absorb light, the same image capture device thatcaptured return light from the first dataset 14 can be used to capturelight from the second dataset 16. The image capture device can captureand identify and authenticate the object 12 having datasets 14, 16 ascombined in the key 205 as part of that object 12. No two objects 12 canhave the same exact authentication pattern image.

If the authorization to scan the key 205 is only limited to the imagecapture device such as a smartphone of the claimant 130, then itguarantees that no fraudulent transaction can proceed. Since thecaptured optical fingerprint information in all transactions and thestored fingerprint in the remote database are encrypted, man-in-themiddle attacks are also not possible.

Reference numeral 400 in FIG. 4 is a flow chart that shows how the key205 can be used to allow single sign-on (SSO) access to any website orrelying party 140. The steps in accessing a website XYZ.com are shown; asimilar process will apply for any digital asset or server. The uservisits the website, in this case XYZ.com, and requests to login withidentity provider ABCD in step 410. The user's browser redirects to theABCD webpage in step 415. The ABCD website instructs the user to openthe ABCD app and scan a barcode displayed on the webpage, which containsa unique session ID, in step 420. The app then directs the user to scanthe key 205 in step 425. The app sends all information, including thekey datasets 14 and 16, and geolocation data and the time of scan to anauthentication server in step 430. The authentication server checks themobile device ID, the key datasets 14 and 16, and the time of scan, andmatches with the stored data in the authentication server in step 435.If any of these parameters do not match, then access to the website isdenied in step 440. If all parameters match, then the ABCD app allowsthe user to choose what information (e.g., name, email address, phonenumber) to share with the relying party 140 in step 445. The ABCDwebpage then redirects the user to XYZ.com with a token containing thisinformation in step 450. In step 455, the user is logged in.

Reference numeral 500 in FIG. 5 is a flow chart that shows how a digitalasset, such as a website or server, can be accessed by the key 205 andan authorized mobile device. FIG. 5 illustrates how the website can beaccessed on a desktop computer by using the key 205 associated with anID card, credit card, key fob, or any article that has the key datasets14, 16 incorporated into it. The same approach can be deployed foraccessing any other digital asset. At step 510, a user attempts to loginto a representative website XYZ.com on the desktop. At step 515, XYZ.comresponds by generating a login request that includes information such asa session ID consisting of random characters, an issue instant thatincludes the time of the request, the web URL (XYZ.com), and anindependent identity provider. All this information may be encoded inthe form of a barcode displayed on the desktop, or displayed in the formof characters, numbers etc. For illustrative purposes, the identityprovider in FIG. 5 is shown as ABCD.com.

Website XYZ.com also instructs the user to open the ABCD app in step 520on the user's authorized mobile device. The user is also instructed toscan the barcode displayed on the website XYZ.com that was created instep 515 that includes information such as a session ID consisting ofrandom characters, an issue instant that includes the time of therequest, the web URL (XYZ.com), and an independent identity providerABCD.com. The app then directs the user to scan the key 205 in step 525.In step 535, the ABCD app parses the login request into separateinformation pieces, such as the session ID, the issue instant, thewebsite URL (XYZ.com), and the identity provider ABCD URL (ABCD.com).The app then sends all this information together with additionalinformation, such as the geolocation coordinates, the time of thebarcode scan, the device ID, and the images of the key datasets 14, 16from the identity provider item to an authentication server in step 540.

In step 550, the authentication server checks that the identity item isunique and authentic by processing the images of the key datasets 14,16. The authentication server then further checks that the device thatis reading the identity item is the authorized device for the identityitem. The authentication server also checks the geolocation coordinatesof the device, the time of the barcode scan, and the issue time. If thedevice ID, the key 205, the geolocation coordinates, or the time duringwhich the access is permitted do not match, then access to the website,server, or digital asset is denied at step 560.

The key 205 and the device together constitute the requisite pair ofkeys, and both of these keys are necessary for the system and process towork. One without the other will not allow the process to go forward.This establishes the identity of the user in a unique manner since thekey 205 and the device belong to only one user. The key 205 cannot becloned or reproduced as described in FIG. 2. The device such as a mobilephone is also unique to the user. Normally, the mobile device is furtherprotected by a biometric, such as a fingerprint or eye scan, or by apasscode of multiple digits only known to the user. If the uniqueidentity item is not authentic and/or if the device is not authorized toread it, then the user is denied access to the digital asset at step560. In addition, in the authentication server database, one can alsostore the authorized time of the day and the days of the week for a userto access the digital asset, and the locations from where a user canaccess the digital asset. Even if the device ID and the unique identityitem match, the authorized time for access and the authorizedgeolocation and the time duration permitted for access must also matchfor a user to access the digital asset.

The arrangement of matching the device and the unique identity item canbe visualized as having two physical keys that are in the possession ofthe user. One physical key is the key 205 that has an identifier in theform of a barcode, RFID or alphanumeric characters as the second dataset16, and that also has the first dataset 14 in the form of a randomdistribution of particles, as shown in FIGS. 2A, 2B. This key 205 cannotbe compromised and cannot be hacked, and no virus can infect it as isthe case with software-based keys or USB devices. The second physicalkey is the device itself, such as the cell phone or other imager-baseddevice that is authorized to read the first physical key 205. Not alldevices are permitted or authorized to read the key 205. The authorizedphysical reading device key is further protected by the biometrics orthe digital passcode or facial recognition, and is assigned to the userand is unique to that user. Besides, both of these keys are in thephysical possession of the user and cannot be hacked.

If the user lost the first physical key 205, then the person who findsthe unique identity item does not have the device authorized to read it,and hence, the find is of no value without the device. If the personloses the device (e.g., the cell phone), then the finder of the devicestill cannot access the website or any server or other digital assetswhere the user has an account, because the finder does not have thecorrect key 205. In addition, as explained earlier, the access to awebsite, server or digital assets can be further controlled by assigningthe geolocation coordinates from where access is permitted and also thetime duration during which the website, server, or any digital asset canbe accessed. If the user wants to access the digital asset from anywhereand at any time, he/she can have it as the default permission. In thedefault state, so long as the requisite pair of the correct key 205 andits associated authorized device match, a user can access the website,server, or any other digital asset where he/she has an account.

In step 565, the authentication server retrieves the web URL (XYZ.com)and fetches the user name for the web URL. The association of the username that has been provided by the user to the website or to any digitalasset where the user has an account and the UIAK is a one-time event,and this user name is then stored in the authentication server. Nopassword needs to be stored in the authentication server. The key 205and the associated mobile device substitute for the user name andpassword and also something that only the user has. The association andregistration of the key 205 having datasets 14, 16 incorporated into itand the user's name that is stored in website XYZ or to any digitalasset will be further explained in connection with FIG. 7.

In step 570, the authentication server uses the session ID, the issuerweb URL (XYZ.com or any server or digital asset), and the associateduser name to send a command to XYZ.com, or to the server or the digitalasset to permit the user to log in. In step 575, the user is logged inwith the user name. If the user so desires, a password can also be addedin this process at a suitable step.

Reference numeral 600 in FIG. 6 is a flow chart that shows a so-calledImpenetrable House of Security (IHS), as well as multiple levels ofsecurities built into such a house before a user can enter a digitalasset 660, such as a website or a server. A first lock typically needsuser identification in a manner such that no one can imitate the user'sidentity. Typically, it is achieved either by a user name and apassword, or by multifactor authentication, or by U2F, or by using USBdevices, etc. as described above. However as described above,sophisticated attackers are capable of breaking the present multifactorauthentication and the third party ID provider's authenticationservices. Therefore, there is a clear need to come up with a betterapproach to secure digital assets from cyber attacks, hacking, andheists while providing authentication and authorization in a securemanner and preferably through a single protocol without the user nameand password other than the use of an authentication site.

In accordance with the present invention, the user's identity andpassword are all replaced by the physical unique identity andauthentication item that has key datasets 14, 16 as an integral part.Once the user is confirmed by the digital asset (e.g., XYZ.com) eitherby user name and password, or by any other authentication means such asmultifactor authentication, or by other approaches, and is associatedwith the datasets 14, 16 of the key 205, the user will not have to everenter a user name or password again to log into the website. Thisassociation and registration is a one-time event in the beginning.Alternately, the digital asset 660 can have the user identified by thekey datasets 14, 16 on the unique identity item at the time ofestablishing the account for the first time.

This physical possession of the unique item key 205 makes it verydifficult for anyone to breach this first lock, because the key 205 isextremely hard to clone, if not impossible, and this key 205 is notprone to any virus or other types of attack. This level of security islabelled as level 1 security 610 in FIG. 6. Typically this first lock isthe only lock that most digital assets (e.g., XYZ.com) have in the formof the user name and password before access is granted to a user. Oncethis first lock is breached, the hacker gets in and can cause havoc.

However, in accordance with this invention, there is at least oneadditional level lock that must also be breached. This level of securityis labeled as level 2 security 620 in FIG. 6. As described above, thekey 205 can only be used with the user's mobile device key. The devicekey is the mobile device of the user that has been specificallyauthorized to scan the first key 205. If a third party such as a hackertries to scan the key 205, then the hacker's device will not work, andhe/she will be denied the access. As described earlier, both the devicekey and key 205 must be operated together to access the digital asset660.

Since most mobile devices are further protected either by biometricssuch as fingerprints, or by eye scans, or by multi-digit passcodes.Unless the user uses one of these to open the mobile device, then thedevice cannot be used to scan the key 205. This level of security islabeled as level 3 security 630 in FIG. 6.

There are additional levels of security that are also provided for highsecurity applications such as defense, financial, government, or otherestablishments where extremely high security is warranted. The level 4security 640 in FIG. 6 limits the time during which the digital asset660 can be accessed, such as weekdays from 8 AM to 5 PM, or any timedesirable by the establishment. The access can be further controlled byassigning the geolocation coordinates from where the access is permittedas shown in level 5 security 650 in FIG. 6. The user may also addanother optional level of security 655 in the form of something thatonly the user knows, such as a passcode or password.

In addition to the security levels provided in FIG. 6, the security canbe further enhanced by having multiple keys 205 and multiple mobiledevices in order to access the digital asset 660. This is especiallyapplicable in highly secure applications. For example, two keys A and Bmay be provided, and one mobile device X may be authorized to read keyA, and another mobile device Y may be authorized to read key B. In thisexample, only when this combination is used, will access be authorizedto a server. An organization may have 3, 4, 5, or any number of keys andany number of authorized mobile devices to work with them. For example,one may require 2 out of 2, or 2 out of 3, or 3 out of 5 keys, to gainaccess to a server.

Hence, any digital asset, website, or server that uses a key 205 of thetype described in FIGS. 2A, 2B that includes the datasets 14, 16, or thedataset 14 alone, or a combination of the datasets 14, 16, and any othermodification coupled with only authorized device/devices that can reador decipher the datasets 14, 16 presents two impenetrable locks tosafeguard the digital asset. Furthermore, the reading or decipheringdevice may also be protected by the user's biometric data, or by amulti-digit passcode, and thus puts another lock to protect the digitalasset. Locks 4 and 5 for controlling the time of access and thegeolocation coordinates from where the digital asset is accessiblefurther protects it from any hacker or unauthorized user. One can alsohave a combination of multiple keys and associated devices to access theserver or digital asset. This Impenetrable House of Security of FIG. 6will reliably protect user privacy and assure him/her security of theirdata.

Reference numeral 700 in FIG. 7 is a flow chart that depicts theregistration, association, and activation of user names of a digitalasset, a website or a server to a key 205. The registration andactivation process can proceed in multiple ways. As shown in FIG. 7, instep 710, an ABCD app on a mobile device starts the registration processand requests from the user the name, the email address, and the mobilephone number of the user in step 720. The user is asked to scan theunique key 205 with the user's mobile device in step 730. This devicewill be linked to the key 205 and together this combination will form apair. Also in step 730, the captured image of datasets 14, 16 will besent to an authentication server. In step 735, the authentication serverchecks if the dataset 14 is three-dimensional in nature, has coloredparticles, and is associated with the dataset 16. If not, the user doesnot have a proper key 205, and the user will be denied access as in step740 and advised to use the correct key 205. If the user does have theproper key 205, then the user is directed to list the user name for thewebsite A that the user would like to login using the key 205 in step745. In step 750, the user lists the user name associated with websiteA. The user name is communicated to website A in step 760 to confirm theuser's identity. The user's identity can be confirmed by multiple waysin order to associate with the key 205 to start with initially. If theuser's identity is not confirmed in step 765, then the user name doesnot belong to the person who is trying to associate that name with thekey 205, and the permission is denied in step 770. If the user'sidentity is confirmed, then in step 775, an email link is sent to theemail listed in step 720, or a text message is sent to the phone numberlisted in step 720. The user then activates the association of the key205 and the mobile device to the user name in step 780 for that websiteor digital asset, and in the future will be able to log in without theuser name or password at that site simply by using the key 205 and theassociated mobile device. In step 785, the user is asked whether anotheruser name at any other digital asset (e.g., website or server etc.)needs to be associated with the same key 205 and mobile device. If so,then the process starts again at step 750. If no further registrationand activation is needed, then the process ends at step 790.

Reference numeral 800 in FIG. 8 is a flow chart that depicts the accessof a website or digital asset using the mobile device itself. A similarprocess will apply for any digital asset or server. The user visits thewebsite, in this case XYZ.com, on the mobile device, e.g., a cell phone,in step 810. The website generates a request that includes randomcharacters, the issue instant, the web URL, and the ID provider in step815. The user clicks a link on the webpage to launch the ABCD app on thedevice, with the request information passed through this link, in step820. The app directs the user to scan the key 205 in step 825. The appparses the request information from the website in step 835. The appsends this information and the key datasets 14, 16, as well asgeolocation data and the time of scan to an authentication server instep 840. The authentication server checks the mobile device ID, the keydatasets 14, 16, and the time of scan and then matches them with thestored data in the authentication server in step 850. If any of theseparameters do not match, the access to the website is denied in step860. If all parameters match, the authentication server retrieves theweb URL and the user name associated with the web URL in step 865. Instep 870, the authentication server uses the session ID, the web URL,and the user name to send a command to XYZ.com to permit the user to login. In step 875, the user is logged in.

Reference numeral 900 in FIG. 9 is a flow chart that depicts how atypical credit card purchase is currently processed. Not all the detailsin card approval processing are shown in FIG. 9, but only the keytransactional details are shown for the sake of brevity. This figureonly highlights the Card-Present (CP) case. A slightly different processis followed in the Card-Not-Present (CNP) case. In step 910, a cardholder presents his/her card to a merchant for buying a product. A cardreader at the merchant site reads the card data and sends it to anacquirer that is generally a merchant bank in step 915. The merchantbank sends the request to a payment brand, e.g., Visa or MasterCard, forapproval in step 920. The payment brand sends a request to the cardissuer that is generally the bank where the cardholder has accounts instep 922. The issuer checks the available credit and the validity of thecard, as well as the fraud situation such as the use of the card at anunexpected location, etc. in step 925. In step 930, the issuer eitherapproves or denies the card payment. If the card is not valid or thecredit is not available, a denial response is sent to the payment brandthat communicates with the acquirer, and the acquirer communicates withthe merchant in step 950. The cardholder is denied the product in step955. If the card is approved by the issuer, a response of approval issent to the payment brand in step 932. The payment brand sends anauthorization code to the acquirer (merchant bank) in step 935. Theacquirer authorizes the transaction in step 937 and sends theconfirmation to the merchant in step 940. Finally, the card holderreceives the product in step 945. Most of these steps are computerizedwith very little human intervention, and some or all of these steps canbe combined in a computer algorithm with a seamless interface andtransmission. Some of these steps may be eliminated.

Reference numeral 1000 in FIG. 10 is a flow chart that describes theprocess of issuing a credit card with the enhanced feature of the key205 incorporated into the card. A card customer requests a payment brandcard from an issuer with the key 205 in step 1005. The issuer checks thecredit history of the customer at step 1010, and if the credit historyis not satisfactory, the card is denied. If the credit history is good,the issuer may decide to issue a credit card to the customer. A cardwith the key 205 and an EMV chip and/or a magnetic stripe is created instep 1025. The EMV chip data, or magnetic stripe data, is associatedwith the key 205. The payment brand/issuer associates an electronicdevice such as one or more mobile phones of the cardholder and thecardholder identity with the key 205 on the card in step 1030.Information on the EMV chip, magnetic stripe data, and the key 205 arestored in an authentication server in step 1035. Some of the steps inFIG. 10 may be combined or eliminated, or the sequence may be altereddepending on the brand owner/issuer processes.

Reference numeral 1100 in FIG. 11 is a flow chart that describes theprocess of authenticating the card with the enhanced key 205 whenpresented to the merchant for purchasing a product. Not all the detailsin card approval processing are shown in FIG. 11, but only the keytransactional details are shown for the sake of brevity. This figureonly highlights the Card-Present (CP) case. In step 1105, a cardholderpresents his/her card to a merchant for buying a product. A card readerat the merchant site reads the card data in the EMV chip, or themagnetic stripe, and also the key 205 in step 1110. In step 1112, the 3Dfeature of the key 205 is ascertained. If the card's authentication key205 does not have the 3D features, the card is rejected, and thepurchase is refused as shown in step 1115. If the 3D feature is present,the merchant reader sends the request with the card information and thekey datasets 14, 16 to the acquirer that is generally the merchant bankin step 1120. The acquirer (merchant bank) sends the request to apayment brand, e.g., Visa or MasterCard, for approval in step 1125. Thepayment brand sends a request to the authentication server where the keydatasets 14, 16 and the associated database are kept, in step 1130. Theauthentication server compares the datasets 14, 16 of the key 205 storedin the authentication server with the data forwarded by the acquirer instep 1135. If the first dataset 14 stored at the address 16 of thesecond dataset of the key 205 does not match with data received from theacquirer in step 1135, then the card is not authentic, and the purchaseis denied in step 1140. If there is a match in step 1135, the request isforwarded to the card issuer that is generally the bank where thecardholder has accounts in step 1145. The issuer checks the availablecredit and the validity of the card, as well as the fraud situation suchas the use of the card at an unexpected location, etc. in step 1147. Ifthe card is not valid or the credit is not available, a denial responseis sent to the payment brand that communicates with the acquirer, andthe acquirer communicates with the merchant in step 1150, and thecardholder is denied the product. If the card is approved by the issuer,a response of approval is sent to the payment brand, and anauthorization code is sent to the acquirer (merchant bank) in step 1152.The acquirer authorizes the transaction in step 1155 and sends theconfirmation to the merchant, and the cardholder receives the product instep 1160. Most of these steps are computerized with very little humanintervention, and some or all of these steps can be combined in acomputer algorithm with a seamless interface and transmission. Some ofthese steps may be eliminated. As mentioned earlier, not all the detailsin card approval processing are shown in FIG. 11, but only the keytransactional details are shown for the sake of brevity.

Reference numeral 1200 in FIG. 12 is a flow chart that describes theprocess of authenticating the card in the Card-Not-Present (CNP)situation. For CNP transactions, the cardholder may input the creditcard information into an e-commerce site as is current practice in step1205. The online e-commerce site submits a request to the acquirer instep 1210. The acquirer sends the request to the payment brand toauthorize the transaction in step 1215. The payment brand sends the cardinformation to the authentication server in step 1220. The card holderis asked to scan the key 205 embedded in the card holder's credit cardusing the cardholder's authorized mobile electronic device such as thecardholder's smartphone in step 1225. In step 1230, the authenticationmodule of the authentication server compares the scanned information ofthe key 205 coming from the mobile electronic device with the storedinformation in the authentication database server. If the first dataset14 of the key 205 stored at the address of the second dataset 16 of thekey 205 does not match with data received from the mobile device/devicesin step 1230 or the data received is not ascertained to contain a 3Dfeature, the card is not authentic, and the purchase is denied in step1235. If the card is found to be authentic, then in step 1240, theauthorization module of the authentication server checks to ascertainthat the electronic device/smartphone is authorized to scan the key 205.If not, then the card user is not the correct user, and the transactioncannot be approved as shown in step 1235.

If the electronic device/smartphone is authorized to scan the key 205,then the authentication server communicates with the payment brand instep 1245 that the card is authentic, and the user is authorized to scanthe card, and thus the card belongs to the user and it is in thepossession of the user. Also, since smartphones/electronic devices thesedays have locking features, the phone can only be opened by inputtingthe password or by a fingerprint reader built into the phone, it is thusdifficult, if not impossible, to place an order on an online sitethrough a counterfeit card. In effect, the user has two private keys.One is the key 205 based on the credit card that is extremely difficultto clone, and the other is the smartphone/electronic device itself withits own built-in authentication features, such as a fingerprint or apassword. Both of these have to be in the possession of an individual toplace an order on an on-line site, thus eliminating fraud completely.

The payment brand sends the request to the card issuer entity in step1250. The issuer checks the available credit. If the credit is notavailable, a denial response is sent to the payment brand thatcommunicates with the acquirer, and the acquirer communicates with theon-line site, and the purchase is denied in step 1260. If the card isapproved by the issuer, a response of approval is sent to the paymentbrand in step 1265 that, in turn, sends an authorization code to theacquirer (merchant bank) in step 1270. The acquirer authorizes thetransaction in step 1275, and the order is placed on the site in step1280. Most of these steps are computerized with very little humanintervention other than the cardholder scanning the key 205 on the card.Some or all of these steps can be combined in a computer algorithm witha seamless interface and transmission. Some of these steps may beeliminated. As mentioned earlier, not all the details in card approvalprocessing are shown in FIG. 12, but only the key transactional detailsare shown for the sake of brevity. Since the authorization to scan thekey 205 is only limited to the credit card holder's smartphone, then itguarantees that no fraudulent CNP transaction can proceed. In step 1205where the cardholder is instructed to submit the card information, theuser name can be eliminated if the e-commerce site is equipped to acceptthe key scanning information directly from the cardholder.

As described above, security is needed for cybercurrencies to protectthe private key both in cold storage and hot storage. FIG. 13A depicts aflow chart that describes a process to insure that the private keyindeed belongs to the owner who owns the private key. The private key isneeded to conduct the transaction on the block chain to move or receivethe currency to/from another public address. The private key may bestored in a storage media, such as a local device or a server, or in thecloud, etc. It is the access to the storage media that should not beaccessible to a hacker. Another feature of this invention is directed topreventing access to the storage media for anyone other than the ownerof that storage media.

Thus, in FIG. 13A, in step 1310, the key 205 and the mobile device thatis authorized to read the key 205, is associated with a storage mediaaddress, such as the Media Access Control (MAC) address where theprivate key is to be located as a one-time event. The MAC address is aglobally unique identifier assigned to network devices, and therefore itis often referred to as a hardware or physical address. In step 1315,the private key is stored in the storage media. The access to the mediais restricted only through the key 205 and the authorized mobile readingdevice. In step 1320, the owner wants to access the private key storedin the storage media. The owner is then requested to scan the key 205 instep 1325. The scanned images and the device information, and thegeolocation coordinates of the scanning mobile device and the authorizedtime during which the scanning is allowed are all sent to anauthentication server in step 1330. The authentication server checks theauthenticity of the key 205 by analyzing the image data from keydatasets 14, 16 and also the device ID, the geolocation data, and thetime of scan in step 1335. If all these parameters are confirmed, theowner is provided access to the media storage to access the private keyin step 1345; otherwise, the access is denied in step 1340. The ownercan sign the transaction with the private key in step 1350.

Reference numeral 1300 in FIG. 13B is a flow chart that describes thelevels of security available to a cryptocurrency owner similar to thesecurity levels described above in connection with FIG. 6. The privatekey is stored in the storage media 1360. The physical possession of thekey 205 makes it very difficult for anyone to breach the first lockbecause the key 205 is extremely hard to clone, if not impossible, andthis key 205 is not prone to any virus or other types of attack. Thisfirst security lock level is shown as 1365 in FIG. 13B. The first lockof the key 205 can only be used with the device key 1370. The device keyis the mobile device of the user that has been specially authorized toscan the key 205. If a third party such as a hacker tries to scan thekey 205, then his mobile device will not work, and he/she will be deniedaccess. Both the device key and the key 205 must be together in thehands of the owner to access the private key. This second security locklevel is shown as 1370 in FIG. 13B. Additionally, most mobile devicesare further protected either by biometrics, such as fingerprints or eyescans, or by a multi-digit passcode. Unless the user uses one of theseto open the device, the device cannot be used to scan the key. Thislevel of security of the mobile device itself is depicted as level 3 at1375 in FIG. 13B.

There are additional levels of security that may also be provided. Thelevel 4 security 1380 limits the time during which the digital asset canbe accessed, such as weekdays from 8 AM to 5 PM, or any time desirableby the private key owner. The access can be further controlled byassigning the geolocation coordinates from where the access to thestorage media will be allowed, as shown by security level 5 at 1385. Inaddition, the owner can further limit access by providingpassword/passcode access as another optional level of security as in1390.

In addition to the security levels provided in FIG. 13B, the owner canfurther enhance the security by providing multiple keys 205 and multiplemobile devices, and by requiring that all or some of them together invarious combinations operate in order to access the storage media. Forexample, two keys A and B may be provided, and one mobile device X maybe authorized to read key A, and another mobile device Y may beauthorized to read key B. Only when both keys A and B are used with thiscombination will access be allowed to storage media 1360. Alternately,both mobile devices X and Y may be authorized to open both keys A and B.The owner may have 3, 4, 5, or any number of keys and any number ofauthorized mobile devices to work with them. The owner of the privatekey may decide to have any desirable combination to reach whatever levelof security is needed. For example, the owner may have 2 out of 2, or 2out of 3, or 3 out of 5 keys with associated mobile devices to haveaccess to the storage media 1360. This method of providing security tothe private key can be used for hot and/or cold storage.

In accordance with still another feature of this invention, people alsotypically keep a large number of identifying articles with them. Thesecould be cards in their wallet, pockets, or purses. These cards includecredit/debit cards, driver's licenses, ID cards, loyalty cards, bordercrossing cards, government issued cards for accessing benefits, voteridentification cards, military cards, and health cards, amongst others.The purpose for these cards is different and therefore one has no choiceexcept to carry all these cards as needed. The identifying articles neednot be in the form of cards. They could be keychains, separate customplastic tags, custom key tags, hand tags, or key fobs. The key 205 inthe form of a physical item or a card can serve all these purposes whilealso allowing access to a website or any secure server.

In order to access any such card, the user can launch an app on theirauthorized mobile device. The app displays various cards/services/assetsthat may be activated on their mobile app as shown in 1401 in FIG. 14A.For illustration purposes, this app is identified herein as TheCard App.Numeral 1405 is an e-mail access icon, numeral 1410 is a server accessicon, numeral 1415 is a Visa credit card access icon, numeral 1420 is aMaster Card access icon, numeral 1425 is an ID card icon, and numeral1430 is the user's health card icon. There may be multiple othercards/services/assets that may be activated by actuating the appropriateicons.

As explained earlier, the key 205 and the authorized mobile devicetogether constitute a requisite pair of two physical keys, and both ofthese keys are necessary to access a card/service/asset. This uniquecombination of the key 205 and the associated mobile device establishesthe identity of the user in a unique manner since the key 205 and themobile device belong to only one user. The key 205 cannot be cloned orreproduced. The mobile phone is also unique to a user. Normally, themobile device is further protected by a biometric, such as a fingerprintor eye scan, or a passcode of multiple digits known only to the user. Ifthe unique identity item is not authentic and/or the device is notauthorized to read it, the user is denied access to any of thecards/services/assets shown in FIG. 14A.

Reference numeral 1400 in FIG. 14B depicts the process by which any ofthe cards/services/assets shown in FIG. 14A can be accessed. When a userwants to access a card/asset/service, he/she will launch the app, e.g.,the TheCard App, on their mobile device or a desktop as shown in step1440. The user is then instructed to scan the key 205 with theauthorized device, and this information is sent to an authenticationserver in step 1445. The authentication server checks if the key 205 andthe mobile device are the requisite pair of physical keys in step 1450.If the answer is yes, the owner is directed to click or tap on thecard/asset/service icon that the owner is attempting to access in step1460. If not, the access is denied in step 1455. In step 1465, theauthentication server also checks if the time to access thecard/asset/service is as authorized by the user and physical locationsfrom where the access is allowed, are appropriate. If not, access isdenied as in step 1470. If yes, then the owner is allowed access to theservice or digital asset in step 1475.

Theft of personal information is possible by hacking various sites suchas those who keep credit histories. Thieves could use this informationto open new lines of credit in a person's name and can obtain loans,mortgages, and credit cards. Social security numbers or equivalent IDnumbers are the primary means of identification for most people in mostcountries. If hackers can access and obtain social security numbers, aperson's identity can be stolen. It is the one unique piece ofinformation that every consumer has. There are other alternatives suchas fingerprints, eye scans, or the face of a person. In some countries,the social security numbers are combined with fingerprints and eye scansand voice patterns to protect an individual's identity.

However, biometric authentication systems are not 100% accurate.Environment and usage can affect biometric measurements. They cannot bereset once compromised. It has also been found that master fingerprintscan trick many systems. Researchers have also discovered that a set offive master fingerprints can defeat a system 65% of the time. And, sincethere is no way to modify your iris, retina or fingerprint, oncesomebody has a working copy of these, there is not much one can do tostay safe.

In accordance with yet another feature of this invention, a person caneasily associate the key 205 with a social security number. Anyorganization that provides credit may ask the credit seeker to provetheir identity by reading their key 205 with an authorized mobile deviceas explained above. This insures the protection of an individual'sidentity.

The steps shown in the various flow charts are provided only forillustration purposes, because the sequence of these steps can be easilychanged, and some of these steps can be combined or eliminated, and someadditional steps may be added. The hardware and software elements neededto perform these steps can be easily changed, or combined and eveneliminated without losing the intent of this invention. The describedsteps are thus only illustrative. In addition, the various levels ofsecurity are provided only for illustration purposes, because more orless security levels may be provided.

1-12. (canceled)
 13. A method for authorizing access by a user to adigital asset of a first entity, comprising: storing a unique deviceidentifier indicative of a mobile device of the user in a database of asecond entity that is independent from the first entity; storing keydata from an authentication key of an authentication tag in the databaseof the second entity, the authentication key including a first datasetcomprised of a random distribution of three-dimensional elements and asecond dataset comprised of machine-readable data elements, theauthentication key uniquely identifying the user; providing the userwith a physical object having the authentication tag and authorizingonly the mobile device having the unique device identifier to read theauthentication key of the authentication tag; reading a sessionidentification code provided by the first entity using the mobile devicein response to the user requesting access to the digital asset, thefirst entity thereafter prompting the user to read the authenticationkey with the mobile device to generate scanned key data; and determiningif the scanned key data read by the mobile device matches the key datastored in the database of the second entity, and allowing access by theuser to the digital asset only if the scanned key data read by themobile device matches the key data stored in the database of the secondentity.
 14. The method of claim 13, further comprising: receiving, fromthe user, a user name and password to the first entity prior to thefirst entity providing the session identification code to the user. 15.The method of claim 13, wherein the reading the authentication key ofthe authentication tag is performed by configuring the mobile device asa portable, handheld, image capture device, and by aiming the imagecapture device at the authentication tag to capture return light fromthe three-dimensional elements.
 16. The method of claim 13, furthercomprising: registering a name of the user with the first entity whenthe scanned key data matches the key data stored in the database. 17.The method of claim 13, wherein the mobile device is authorized to readthe authentication key of the authentication tag by comparing a deviceidentifier of the mobile device with the unique device identifier storedin the second database upon the mobile device reading the sessionidentification code.
 18. The method of claim 13, wherein themachine-readable data elements of the second dataset are encoded in atleast one Radio Frequency Identification (RFID) chip.
 19. The method ofclaim 13, further comprising: displaying a plurality of icons indicativeof at least one of a card, a service, an asset on the mobile device, andactivating a selected icon when the scanned key data matches the keydata stored in the database of the second entity.
 20. The method ofclaim 13, further comprising: storing a second unique device identifierindicative of a second mobile device of a second user in the databaseand determining if the scanned key data read by both the mobile deviceand the second mobile device matches the key data stored in the databaseof the second entity; and allowing the user to access the digital assetonly if the scanned key data read by both the mobile device and thesecond mobile device matches the key data stored in the database of thesecond entity.
 21. The method of claim 13, wherein the sessionidentification code includes a plurality of session parameters that arecaptured by the mobile device in response to an access request.
 22. Themethod of claim 21, wherein at least one of the plurality of sessionparameters comprises geolocation coordinates of the mobile device.
 23. Asystem for authorizing access by a user to a digital asset, the userutilizing a mobile device with a unique device identifier, comprising: afirst entity possessing the digital asset; a second entity independentfrom the first entity that stores the unique device identifier of themobile device and stores key data from an authentication key of anauthentication tag in a database, the authentication key including afirst dataset comprised of a random distribution of three-dimensionalelements and a second dataset comprised of machine-readable dataelements, the authentication key uniquely identifying the user; aphysical object having the authentication tag with the authenticationkey, the authentication key capable of only being read by the mobiledevice having the unique device identifier; and a computing deviceindependent from the mobile device, the computing device displaying asession identification code provided by the first entity in response tothe user requesting access to the digital asset through the computingdevice, the first entity prompting the user to read the authenticationkey to generate scanned key data upon the mobile device reading thesession identification code, the first entity allowing access by theuser to the digital asset only if the scanned key data read by themobile device matches the key data stored in the database of the secondentity.
 24. The system of claim 23, wherein the user provides a username and password to the first entity using the computing device priorto the first entity providing the session identification code to theuser.
 25. The system of claim 23, wherein the mobile device reads theauthentication key of the authentication tag by configuring the mobiledevice as a portable, handheld, image capture device, and by aiming theimage capture device at the authentication tag to capture return lightfrom the three-dimensional elements.
 26. The system of claim 23, whereinthe physical object comprises a storage medium that stores theauthentication key that can only being accessed by the mobile devicehaving the unique device identifier.
 27. The system of claim 23, whereinthe session identification code includes a plurality of sessionparameters that are captured by the mobile device in response to anaccess request.
 28. The system of claim 27, wherein at least one of theplurality of session parameters comprises geolocation coordinates of themobile device.
 29. The system of claim 23, wherein the mobile device isauthorized to read the authentication key of the authentication tag bycomparing a device identifier of the mobile device with the uniquedevice identifier stored in the second database upon the mobile devicereading the session identification code.
 30. The system of claim 23,wherein the machine-readable data elements of the second dataset areencoded in at least one Radio Frequency Identification (RFID) chip. 31.The system of claim 23, wherein a second user utilizes a second mobiledevice having a second unique device identifier, the second uniquedevice identifier being stored in the database, the first entityprompting both the user and the second user to read the authenticationkey to generate scanned key data upon both the mobile device and thesecond mobile device reading the session identification code, the firstentity allowing access by the user to the digital asset only if thescanned key data read by both the mobile device and the second mobiledevice matches the key data stored in the database of the second entity.32. The system of claim 23, wherein additional key data from anadditional authentication key of the authentication tag that uniquelyidentifies the physical object is stored in the database, the firstentity allowing access by the user to the digital asset only if scannedadditional key data read by the mobile device matches the additional keydata stored in the database.